The use of spoofed hyperlinks has recently grown to the point that it is undermining many desirable forms of electronic communications. In this discussion, email message spoofing is used as a primary example, but it is not the only example of this growing problem and the discussion provided here should not be interpreted as restrictively applying only to email.
One of the biggest problems now preventing email from becoming a legitimate means of business communications is email message spoofing. A spoofed email message is one that appears to the receiver to have come from a perfectly legitimate source, usually a reputable individual, firm, or company. The message includes one or more spoofed hyperlinks that lead the receiver down a path such that the receiver is asked to reveal some “important” data, usually personal data like a social security number, account number, personal identification number (PIN), etc. Since the email message and the supporting web site linked to it appear to be completely authentic (sometimes even including the use of images stolen right from a legitimate entity's web site), the end user is usually completely unaware of what is going on.
FIG. 1 (background art) is a block diagram depicting a representative spoofing scheme 10. There are three parties 12 involved: a customer, client, or user (user 14) whom we are trying to protect; a trusted firm or organization (organization 16) that wants to use an electronic communication or email message (email 18) for business communications without worrying about spoofing; and an attacker or spoofer (spoofer 20) who sends a spoofed email 22 in an attempt to elicit a response 24 from the user 14 to learn personal data or confidential information (information) for malicious purposes.
The parties 12 each use appropriate computerized devices to send and receive the email 18, spoofed email 22, and response 24. For example, the organization 16 may used computerized workstations or terminals and a server; the user 14 may use a personal computer (PC) or personal digital assistant (PDA), and the spoofer 20 may use a PC and a server. For the sake of simplification we herein treat the parties 12 and the hardware they use as synonymous.
The trusted organization 16 has a business relationship with its users 14 and may or may not have used email to previously communicate with them. FIG. 1 shows an organization-to-user path 26 for conventional email 18, as well as a user-to-organization path 28 for a user's requested action, typically initiated by the user 14 following a URL to the web site of the organization 16.
The problem is that the spoofer 20 can send the spoofed email 22 to the user 14 via an undetected spoofer-to-user path 30. Upon receipt of such a spoofed email 22, the user 14 may respond under the assumption that the organization 16 is requesting information. However, rather than the response from the user 14 proceeding via the intended user-to-organization path 28 it proceeds via an unintended user-to-spoofer path 32 to the spoofer 20. Unaware of the deceptive tactics being employed, the user 14 may then divulge information that would not otherwise be shared with the spoofer 20.
A recent example of this involved a large U.S. bank, its customers in the U.S. and spoofed emails with links that led to a computer server listed in Internet IP address databases as belonging to a futures trading company in China. The spoofed emails appeared to be from the U.S. bank, including original trademark logos and other images that were actually linked in via HTML code from the U.S. bank's own web servers in the continental United States. The spoofed emails informed the receivers that there had been a change in the bank's terms and conditions related to their accounts, and invited them to click a link to view the new terms and conditions. The link in these spoofed emails, however, led to the server in China rather than to the U.S. bank's website on a server in New York. These spoofed emails were sent to at least thousands of people, most of whom did not even have accounts with the bank and who simply deleted them. Unfortunately, many people who were the customers of the U.S. bank, probably numbering at least in the hundreds, received and clicked on the link in these spoofed emails.
The text labeling this link read “Click here to access our terms and conditions page . . . ” while the actual content of the link resembled:
h_r_e_f=“h_t_tp://w_w_w.SomeBank.c_o_m:ac%398HAAA9UWDTYAZJWVWAAA A9pYWwgc216Z-T00PjxTVgc216ZT00PjxT3Aac%398HAAA9UWDTYAZJWVWAAAA9pYWwgc216ZT00PjxTVgc216Z- T00PjxT @200.0.0.0/c_g_i-b_i_n/s .pl?m=receiver @isp.c_o_m”6ZT00PjxTVgc2l6ZT00PjxT@200.0.0.0/c_g_i-b_i_n/s.pl?m=receiver@isp.c_o_m”
The link thus overtly contained the U.S. bank's web address, but actually covertly linked to a server at the IP address 200.0.0.0 (changed here from the actual IP address used), and worked to send the receiver's email address (e.g., receiver@isp.com) when the link was clicked. With this alone, the spoofer learned the email addresses of receivers who likely had accounts with the U.S. bank, as well as the fact that those particular receivers would easily rely on spoofed emails. Furthermore, once such a naive receiver clicked on the link and arrived at IP address 200.0.0.0, they could be greeted with a request for private information, such as: “So we can determine your account type and present the specific terms and conditions applicable for it, please enter your account number.”
As can be appreciated from this single example, spoofing can employ quite sophisticated social engineering and poses a serious threat to legitimate companies and firms and to their customers and clients.
Unfortunately, while very serious and constituting a problem approaching epidemic proportion, spoofed emails 22 are merely the most notable current symptom of what is actually a much larger and rapidly growing problem. Hyperlinks (links) in instant messages (IM), web pages, etc. are also subject to spoofing. To facilitate discussing the larger problem here, and the inventor's solution discussed presently, we generically term the medium in which spoofed links can appear as “messages.”
As messages containing spoofed links are sent to users, the problem becomes how to alert the users to the links in those that are being spoofed. Unfortunately, as can be seen from the email-based message example above, this is often quite difficult because the spoofed links may appear as normal ones, with only extremely detailed analysis of the context they are in allowing the user to uncover aspects which show the link to be a spoofed one.
However, an alternative way to consider the problem here is to flip it over. Rather than ask how can a user know a link is inauthentic, ask how can a user know that a link in a message is authentic? This, combined with some education (i.e., if a message does not present itself as being authentic, then it is not) can certainly slow down the spoofing problem. However, this still leaves the problem of how does a message “present” itself as being authentic. Many in this field feel that it will be very difficult to completely eliminate the spoofing problem without a universal secure messaging solution, for instance, a system where every message is digitally signed at origin. However, because signing and verifying every message is cumbersome, there remains a need for a “next best” solution that is both easy to deploy and easy for users to understand.